1. Field
The disclosed embodiments generally relate to database management and in particular to application version management and out-of-place upgrades.
2. Brief Description of Related Developments
Generally applications cannot share the same database with multiple versions of the same application. Programs and documents will generally include identifiers or schemas that allow it to identify which version of an application or element to which it relates was used. Namespaces can generally be used for identifiers. Namespaces are bound to schemas, or hard-coded, in order to know exactly which version of each element was used. The underlying application will consult the schema locations defined in the namespace for the corresponding version. Thus, in order to make use of multiple versions of the same application, the use of separate database instances is required. However, there are times when it is desirable to be able to have more than one version of an application running on a single database application or such other system, such as for example evaluating an upgrade or other change to an existing application. It may not be desirable to immediately move from the existing application version, which is know to be working, to the upgraded version, until there is an opportunity to evaluate the upgrade against the working environment. For example, it may be desirable to evaluate how data, bound to an original version, will work with an upgraded version of the underlying application. While it may be possible to establish a separate “test” or evaluation system just for this purpose, there are certain costs associated with a separate system that may not be economical or desired.
Different versions of an application typically require the use of separate instances. For example, if the software of a database was upgraded from release 1 to release 2, the database tables need to be upgraded. After the upgrade, the database tables from release 1 will no longer exist, since they have been converted to release 2, and it is not possible for release 1 and release 2 to co-exist in the same database at the same time. Typically, the release or version requires the availability of the resources associated with the entire database and cannot be shared. It should be noted that although the examples will be drawn to a “database” system, the applications of the disclosed embodiments are not so limited in scope, and can pertain to any suitable computerized application, program or system.
For example, an installation of an Oracle Application Server™ would require a separate database instance per each instance of the application server. Not only does this consume a great deal of resources, it may also require several database licenses, as well as management of several difference databases. This may not be a time, resource or cost effective solution.
However, there are advantages for a single database instance to be able to store multiple versions of the same software. For example, a customer having one relational database management system (“RDBMS”) might want to create two separate systems, a production system and a test system for example, in order to evaluate any changes or upgrades to the underlying or base application. The production system could be used to run the customer's business with the original or unmodified version of the application, while the test system could be used to evaluate a new version of the software or new development of applications that would not be intended to impact the production system.
One problem faced in the above example is that each application, the production system and the test system, will presume that it is the only occupant of the database and will reserve the use of the hard-coded schema names. For example, a PAYROLL application would reserve and use the schema name “PAYROLL”. This will not allow a release 1 version of “PAYROLL” to co-exist with a release 2 (production system) version of “PAYROLL” and a release 2 (test system) version of “PAYROLL” in the same database, because schema names are hard-coded and unique within a database management system.
Another problem faced for customers who upgrade from release 1 to release 2 is creating a reliable way to record the progress of an upgrade in the database itself, and keep track of which application is at which version. For example, if there is a Payroll application, a Benefits application, an Inventory application, and an Accounts Payable application, all running on the same database, it would be important to know that the Payroll and Benefits applications are upgraded to release 1 and that the Inventory and Accounts Payable applications are upgraded to release 2. This knowledge is important because newer versions of software have new capabilities, and these require database schema changes from release 1 to release 2. There may also be interaction between each application that requires each application to know the software version of the other. For example, features of a release 1 version of Payroll may not work with or interact properly with a release 2 version of the Benefits application. It would thus be advantageous to have a central repository that keeps track of all installed components and their application (for example Production-system and Test-system) to coexist simultaneously in the same database management system. Current software does not permit this. For example, an in-place upgrade from version X to version Y of the underlying application is “destructive” in the sense that instances of the version X application will not be able to interact with instances of the version Y application.
Attempts of applications to keep track of their schema versions is carried out in an adhoc and individual manner. It would be advantageous to allow for a unified way to keep track of multiple application running on a database.
Also, application upgrades are generally a manual process and each application in the instance of the same system must be upgraded independently of each other. This tends to be a process that is laborious, error-prone, difficult to plan for and execute, and requires system “downtime”. It would be advantageous to have a centralized repository of version information that will permit the creation of automated upgrade tools that are capable of upgrading many different applications at once.
Prior solutions store version information for the purpose of upgrade and installation. It would be advantageous to be able to run multiple versions or multiple instances of the same software at the same time, all within a single database instance.